Non-EMF Domain Objects

By default Graphiti supports domain models from the EMF world and offers automated support for reacting to changes and updating the editor or viewer. Since not only EObjects but simple POJOs can be passed to all relevant framework APIs, it is also possible to use non-EMF domain objects with Graphiti. This page describes the differences the user of Graphiti has to deal with when using non-EMF domain models.

Domain Model Change Notifications

Of course the framework cannot support automated notification to changes in such domain models, so the tool builder needs to hook an appropriate listener into the framework. Here's the process how to do this:

1. Create an appropriate specific domain listener class. As an example you can have a look at DomainModelChangeListener in the Graphiti framework; this class does this job for EMF models.
2. Subclass DiagramBehavior and override its method registerBusinessObjectsListener. In that method create an instance of your listener from step 1 and register it.
3. Create an appropriate notification service class by subclassing DefaultNotificationService or implementing its interface. An instance of this class is used by the framework to get the connection between domain objects and their graphical representation (method calculateLinkedPictogramElements) and triggers the actual update of the graphical representation in the diagram (method updatePictogramElements) using the appropriate update features. The class DefaultNotificationService does the job for EMF models.
4. In your Diagram Type Provider implementation create and return an instance of the class from step 3 within the method getNotificationService.

Support for Undo and Redo

For standard EMF domain models users do not need to care about implementing undo/redo functionality within their features. This is all cared about by the framework by using EMF TransactionalCommandStacks and RecordingCommands for executing features. But in case users have domain models implemented in another technology than EMF, they need to care about implementing undo/redo for their domain model changes by themself. (The changes done to the graphical representation (Graphiti PictogramElements and GraphicsAlgorithms) are still handled automatically.)

In order to provide undo/redo for non-EMF domain models users can implement the interface ICustomUndoRedoFeature within their features. In case a feature implements this interface the Graphiti command stack will care about the EMF undo/redo and additionally to the standard EMF-undo/redo call the appropriate methods (canUndo and preUndo/postUndo resp. canRedo and preRedo/ postRedo) within the feature.

Inside the feature coding for those methods users can use the information passed (the executed feature instance will be called with the instance of its context) to undo the operations done while executing the feature. Within the features execute method users might add additional information needed to perform the undo to the context object.

The decision to implement ICustomUndoRedoFeature can be taken individually for each feature.

For the pattern approach a similar interface has been introduced: ICustomUndoRedoPattern, for which the before mentioned also applies accordingly.

By introducing this functionality it is now possible for users of Graphiti to implement undo and redo functionalities also for non-EMF domain changes; nevertheless this functionality might also by used for EMF domain models in case they need to implement additional undo/redo functionality that is executed either before or after the EMF undo/redo.

Still there is one thing to be aware of: All changes done inside the Graphiti diagram editor or viewer (no matter if EMF changes or non-EMF changes) will write an IExecutionInfo entry to the stack that will be available with the according feature and context for undo/redo. External changes (e.g. changes done from the standard property sheet) will not break the tool, but will not necessarily lead to data being available inside the IExecutionInfo object written:

• EMF changes done on the EMF command stack (e.g. from the standard property sheet) have no associated feature and context. Therefore an empty IExecutionInfo entry will be written. On the other hand all changes done in that case will automatically be undone/redone by the EMF command stack, so there should be no need to do additional stuff
• Non-EMF changes done e.g. from a standard property sheet will naturally not go through the EMF command stack of the tools, so no IExecutionInfo stack entry will be written (in fact also no EMF command stack entry will be written so there is no issue within the tool). In this case users are responsible to add their own undo/redo functionality relying on whatever technology they use for their domain model.